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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server 
(http://www.etsi.org/ipr). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol 
Harmonization over Networks (TIPHON). 



Introduction 



The present document describes interoperability and compatibility tests for H.323 [8] entities concerning the different 
TIPHON Scenarios. It is not intended to provide an exhaustive testing of all facets of H.323 and SCN operation. 
Specific configurations were chosen to provide coverage of the more common commercial deployments. 

The test cases specified in this test plan shall be performed on many different platforms. Therefore, specific details on 
how to perform each test are not included, only instructions on what information shall be exchanged are included. 
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1 Scope 

The scope of the present document is to define interoperability test specifications for the following scenarios: 

• PC to PC; 

• PC to Phone; 

• Phone to PC; 

• Phone to Phone using IP; 

• PC to PC using the SCN. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[I] ETSI TS 101 319: "Telecommunications and Internet Protocol Harmonization Over Networks 
(TIPHON); Signalling for basic calls from a H.323 terminal to a terminal in a Switched-Circuit 
Network (SCN)". 

[2] ITU-T Recommendation E.164: "The international public telecommunication numbering plan". 

[3] ITU-T Recommendation G.711: "Pulse code modulation (PCM) of voice frequencies". 

[4] ITU-T Recommendation G.723. 1 (1996): "Dual rate speech coder for multimedia communications 

transmitting at 5.3 and 6.3 kbit/sec". 

[5] ITU-T Recommendation G.729: "C source code and test vectors for implementation verification of 

the G.729 8 kbit/s CS-ACELP speech coder". 

[6] ITU-T Recommendation H. 225.0: "Call signalling protocols and media stream packetization for 

packet-based multimedia communication systems". 

[7] ITU-T Recommendation H.245: "Control protocol for multimedia communication". 

[8] ITU-T Recommendation H.323: "Packet-based multimedia communications systems". 

[9] ETSI TS 101 321 (V1.4): "Telecommunications and Internet Protocol Harmonization Over 

Networks (TIPHON); Inter-domain pricing, authorization and usage exchange". 

[10] ETSI TS 101 312 (VI. 3): "Telecommunications and Internet Protocol Harmonization Over 

Networks (TIPHON); Network architecture and reference configurations; Scenario 1". 

[II] ETSI TS 101 313: "Telecommunications and Internet Protocol Harmonization Over Networks 
(TIPHON); Network architecture and reference configurations; Phase II: Scenario 1 + Scenario 2". 

[12] ITU-T Recommendation G.728: "Coding of speech at 16 kbit/s using low-delay code excited linear 

prediction" . 
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3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



A 


Audio 


ARQ 


Admissions Request 


ACF 


Admissions Confirm 


ARJ 


Admissions Reject 


D 


Data 


DRQ 


Disengage Request 


DTMF 


Dual Tone Multi Frequency 


IP 


Internet Protocol 


LRQ 


Location Request 


LCF 


Location Confirm 


QoS 


Quality of Service 


SCN 


Switched Circuit Networks 



Test Strategy 



Interoperability testing should be performed after a vendor has completed product and system testing with its own test 
procedures. To progress interoperability testing, the vendor's test procedures should include those contained in the 
present document. The purpose of interoperability testing is to test compatibility with other products, which use the 
same TIPHON specifications. 



Scoring 



The present document has integrated the scoring sheets into the description of the call flow. To score a test simply fill in 
a ok in the succeed box, if this event did not occur put in a -. If this line is not applicable for the test just check n.a. 

There will be electronic forms that automatically calculate the percentage of the successful executed parts of the test and 
the output will be a simple percentage value. 



6 Overview 



For setup of equipment, the present document uses a number of basic configurations. These are used to run a certain 
number of tests. 

The basic configurations are: 

1) Terminal <-> Terminal; 

2) Telephone <-> Terminal; 

3) Telephone <-> Telephone using IP as a transit Network; 

4) Terminal to Terminal using SCN as a transit Network. 

Using these test configurations a number of different tests are performed. For example a call first from the Telephone to 
the Terminal and then the other way around or using different codex. 

These tests can include a variety of special features like FastConnect, H.245 tunnelling, security or QoS. 

The number of Gatekeepers involved in these configurations depends on the actual executed test. 

All the call flows shown in the tables are an example flows that should be followed if possible. In some cases not all the 
described messages occur. 
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Prerequisites 



7.1 IP related 

The following prerequisites are taken from TIPHON specifications: 

ITU-T Recommendation H.323 [8] and TS 101 319 [1] shall be used; 

ITU-T Recommendation H. 225.0 [6] FastConnect shall be used for all calls; 

ITU-T Recommendation H.245 [7] Tunnelling shall be used whenever H.245 messages are exchanged; 

TS 101 321 [9] shall be used; 

Gatekeeper Routed Signalling is mandatory, Direct Routed Signalling is optional; 

Originating Terminals and Originating Gateways should always use ARQ (LRQ is optional); 

the Gatekeeper to register with, should be configured manually, using the IP-Address; 

H.323 Terminals shall register to the Gatekeeper using a E. 164 [2] alias only; 

Gateways shall register to the Gatekeeper using Prefixes only; 

Endpoints shall support the keep Alive procedure as specified in subclauses 7.2.2 and 8.4.2 of 
ITU-T Recommendation H.323 [8]; 

if Fast Connect procedure is used, the SETUP Message shall include the fastStart Parameter, and the fast 
parameter shall be returned in exactly one message including the CONNECT Message. 

7.2 SCN related 

To identify the different types of SCN interfaces the following shall be considered: 

• TS 101 312 (V1.3) [10] (TIPHON Phase I, Scenario 1, Architecture) § 4.1 identifies 4 different reference points 
between IP Networks and SCN: El between GW and PSTN, E2 between GW and ISDN, E3 between GW and 
GSM and E4 between GW and PISN. All E Reference points may be User to Network interfaces (UNI) or 
Network to network interfaces (NNI). 

The TIPHON Phase II document (TS 101 313 [11]) identifies additionally for all types of SCN's a separation in 
an E.a reference point between Media Gateway and SCN and an E.b reference point between Signalling Gateway 
and SCN. 

• If the SCN interface is an UNI interface, the gateway can play either the "role" of the user or of the network side. 

• If the SCN interface is an (P)NNI interface, the gateway (or two gateways connected by the IP) can offer two 
types of services in principle: 

Transparent transfer of SCN Signalling across IP connections. 

Signalling interworking between SCN and IP "transit nodes". 

(P)NNrs are located between Originating, Transit and Terminating Network nodes. 

• The testing of SCN behaviour at decomposited gateways requires the simultanious test at two different SCN 
interfaces, details are for further study. 
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Parameter for each test 



There are some extra parameters that can be selected for each test: 



8.1 



Audio Codec 



As TIPHON is not only focussing on the call establishment but also on the Media stream, the audio codec should be an 
extra parameter that should vary from test to test. 

Here is a list of all Codec that are defined in ETSI TIPHON: 

- ITU-T Recommendation G.7 1 1 [3] ; 

- ITU-T Recommendation G.723 . 1 [4] ; 

- ITU-T Recommendation G.728 [12]; 

- ITU-T Recommendation G.729 [5]; 

- GSM Full Rate; 

- GSM Half Rate. 

Which codec is selected should be specified prior to the test. 

8.2 Number of intermediate Gatekeepers 

All tests can be executed with one or more Gatekeepers. The Number of Gatekeepers is just another parameter for these 
tests. 

The description has to be extended accordingly, if more than 2 Gatekeepers are involved. 

If only one Gatekeeper is participating in a scenario, simply mark the not relevant lines of the table with n.a. in the 
succeeded column and simply ignore them. 



Configurations 



9.1 



Terminal to Terminal 



□. 



IP 



Gatekeeper A 



IP 



(RTP/RTCP) 



□ 



is; 

IP 



Gatekeeper B 



NOTE: Gatekeeper B is only present in specific test cases. 

Figure 1 : Terminal to Terminal 

All tests can be executed with one or more Gatekeepers. The Number of Gatekeepers is just another parameter for these 
tests. 
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Direction 


Description 


Test Flow 


Extra feature 


Comment 


A1 -> B1 


Successful call 


9.1.1 


Fast connect 


TIPHON Scenario 


B1->A1 


Successful call 


9.1.1 


Fast connect 


TIPHON Scenario 


A1 -> B1 


Successful call 


9.1.3 


Fast connect 
fallback 


TIPHON Scenario 


B1->A1 


Successful call 


9.1.3 


Fast connect 
fallback 


TIPHON Scenario 


A1 -> B1 


Successful call 


9.1.1 


H. 245 tunnelling 


TIPHON Scenario 


B1->A1 


Successful call 


9.1.1 


H. 245 tunnelling 


TIPHON Scenario 


A1 -> B1 


Successful call 


9.1.4 


H. 245 tunnelling 
fallback 


TIPHON Scenario 


B1->A1 


Successful call 


9.1.4 


H. 245 tunnelling 
fallback 


TIPHON Scenario 


A1 <-> B1 


DTFM Tones 


t.b.d 


DTMF transmission 




A1 ->D 


Basic unsuccessful call 


9.1.2 




TIPHON Scenario 


B1 ->D 


Basic unsuccessful call 


9.1.2 




TIPHON Scenario 



9.1 .1 Successful call from a H.323 Terminal to another H.323 Terminal 

This test verifies the TIPHON Scenario-0 service where the Originating Terminal and the Terminating Terminal are 
registered with the same Gatekeeper or where the two Gatekeepers have a trusted relationship. 



No. 


Action 


Succeeded 


1 


Both Terminal A1 and the Terminal B1 shall register with their respective Gatekeeper(s). 




2 


Terminal A1 initiates a call using a E.I 64 address. 




3 


Terminal A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A issues LRQ (uni/multicast) to Gatekeeper B. * 




5 


Gatekeeper B returns LCF. * 




6 


Gatekeeper A returns ACF. 




7 


Terminal A1 sends SETUP its Gatekeeper (including fast connect options). 




8 


Gatekeeper A forwards SETUP to Gatekeeper B. * 




9 


Gatekeeper B forwards SETUP to Terminal B1 . 




10 


Terminating Terminal B1 performs ARO/ACF sequence. 




11 


Terminal B1 sends an ALERT Message back. 




12 


The User at Terminal A1 should be informed that the other Terminal is alerting. 




13 


After Terminal B1 has accepted the call, the CONNECT message should travel back to the 
originating Terminal A1 . 




14 


Media is exchanged and quality Is evaluated. 




15 


Terminal A1 terminates the call and 

sends a RELEASE_COMPLETE and a DRQ to its Gatekeeper. 




16 


The Gatekeeper(s) forward(s) the RELEASE_COMPLETE to the Terminal B1 . 




17 


The User at Terminal B1 should be informed that the remote peer terminated the call. 




18 


The Terminal B1 should send the DRQ to its Gatekeeper. 





* only present if this test is run with two Gatekeepers 

9.1 .2 Unsuccessful call from H.323 Terminal to another H.323 Terminal 

This test verifies the TIPHON Scenario-0 service where the Originating Terminal and the Terminating Terminal should 
be registered with the same Gatekeeper or where the two Gatekeepers have a trusted relationship, but the connection 
fails as the Terminating Terminal is not registered. 



No. 


Action 


Succeeded 


1 


Both Terminal A1 and the Terminal B1 shall register with their respective Gatekeeper(s). 




2 


Terminal A1 initiates a call using a E.I 64 address. 




3 


Terminal A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A issues LRQ (uni/multicast) to Gatekeeper B. * 




5 


Gatekeeper B returns LRJ. * 




6 


Gatekeeper A returns ARJ. 




7 


The user should be informed that the call failed indicating the cause. 





only present if this test is run with two Gatekeepers 
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If there are three Gatekeepers involved, the procedure should be extended accordingly. 

9.1 .3 Fast Connect Fallback to H.245 tunneling 

This test verifies the support of fallback for the Fast Connect Procedure. 

The calling party shall include the fastConnect parameter in the setup message and set the h245Tunneling to TRUE. The 
called party shall not include the fastStart IE in any message but set the h245Tunneling to TRUE. As a result, the call 
has to be established using a H. 225.0 tunnel for the H.245 connection. 

The high level call flow is described in 9. 1 . 1 . 

9.1 .4 H.245 Tunneling Fallback to plain H.245 

This test verifies the support of fallback for the H.245 tunnehng Procedure as described in 8.2.1 of H. 323 [8]. 

The calling party shall not include the fastConnect parameters in the setup message, but set the h245Tunneling 
parameter to TRUE. The called party shall set the h245TunneIing element to FALSE. As a result the call has to be 
established using a separate H.245 connection. 

The high level call flow is described in 9. 1 . 1 . 



9.2 Terminal <-> Telephone 



□ 



a 



Terminal A1 
IP 



Gatevtay B1 
IP 



-SCN- 



a 



Telephone 



-*^ 



Gatekeeper A Gatekeeper B 

NOTE: Gatekeeper B is only present in specific test cases. 

Figure 2: Terminal <-> Telephone 

All tests can be executed with one or more Gatekeepers. The Number of Gatekeepers is just another parameter for these 
tests. 



ETSI 



11 



ETSI TS 101 335 V3.0.2 (2000-05) 



Direction 


Description 


Test Flow 


Extra feature 


Comment 


A1 -> Tel 


Successful call 





Fast connect 


TIPHON Scenario 1 


Tel -> A1 


Successful call 





Fast connect 


TIPHON Scenario 2 


A1 -> Tel 


Successful call 


9.2.9 


Fast connect 
fallback 


TIPHON Scenario 1 


Tel -> A1 


Successful call 


9.2.9 


Fast connect 
fallback 


TIPHON Scenario 2 


A1 -> Tel 


Successful call 





H.245 tunnelling 


TIPHON Scenario 1 


Tel -> A1 


Successful call 





H. 245 tunnelling 


TIPHON Scenario 2 


A1 -> Tel 


Successful call 


9.2.10 


H.245 tunnelling 
fallback 


TIPHON Scenario 1 


Tel -> A1 


Successful call 


9.2.10 


H.245 tunnelling 
fallback 


TIPHON Scenario 2 


Tel -> A1 


Successful call 


t.b.d 


Overlapped 
sending 




Tel <-> A1 


Successful call 


t.b.d 


DTIVIF transmission 




A1 ->D 


Basic unsuccessful call 


9.2.3 




TIPHON Scenario 1 


A1 -> Tel X 


Unsuccessful call with 
voice after disconnect 


9.2.4 




TIPHON Scenario 1 


A1 -> Tel X 


Unsuccessful call with 
voice before connect 


9.2.5 




TIPHON Scenario 1 


Tel-> D 


Basic unsuccessful call 


9.2.6 




TIPHON Scenario 2 


A1 -> Tel 


Authorization and Call 
Routing via Settlement 
Server 


9.2.7 




TIPHON Scenario 1 


A1 -> Tel 


Usage Report to 
Settlement Server 


9.2.8 




TIPHON Scenario 1 



9.2.1 Successful call from a H.323 Terminal to a Telephone 

This test verifies the TIPHON Scenario- 1 service where the Originating Terminal and the Terminating Gateway are 
registered with the same Gatekeeper or where the two Gatekeepers have a trusted relationship. 



No. 


Action 


succeeded 


1 


Both Terminal A1 and the Gateway B1 shall register with their respective Gatekeeper(s). 




2 


Terminal A1 initiates a call using a E.I 64 address. 




3 


Terminal A1 sends ARO to Gatekeeper A. 




4 


Gatekeeper A issues LRO (uni/multicast) to Gatekeeper B. * 




5 


Gatekeeper B returns LOF. * 




6 


Gatekeeper A returns ACF. 




7 


Terminal A1 sends SETUP to its Gatekeeper (including fast connect options). 




8 


Gatekeeper A forwards SETUP to Gatekeeper B. * 




9 


Gatekeeper B forwards SETUP to Gateway B. 




10 


Terminating Gateway B performs ARO/ACF sequence. 




11 


Gateway B initiates call establishment to SON. 




12 


After the ALERT IVIessage was received on the SCN side, it should be forwarded to the Terminal. 




13 


The User at the Terminal should be informed that the Telephone is ringing. 




14 


After the Telephone was picked up, the connect message should be forwarded from the Gateway 
to the Terminal and Media should be present immediately. 




15 


IVIedia is exchanged and quality is evaluated. 




18 


Terminal A1 terminates the call and 

sends a RELEASE_GOIVIPLETE and a DRO to its Gatekeeper 




17 


The Gatekeeper(s) forward(s) the RELEASE_GOI\/IPLETE to the Gateway. 




18 


The Gateway initiates a call de-establishment to the SON. 




19 


The User at the Telephone should hear appropriate tones. 




20 


The Gateways should send the DRO to its Gatekeeper, after all resources associated with this call 
were released. 





* only present if this test is run with two Gatekeepers 

If there are three Gatekeepers involved, the procedure should be extended accordingly. 
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9.2.2 Successful call from a Telephone to a H.323 Terminal 

This test verifies the TIPHON Scenario-2 service where the Originating Gateway and the Terminating Terminal are 
registered with the same Gatekeeper or where the two Gatekeepers have a trusted relationship. 



No. 


Action 


succeeded 


1 


Both Terminal A1 and the Gateway B1 shall register with their respective Gatekeeper(s). 




2 


Telephone should dial a number to reach Terminal A1 
this can be done using one or two stage dialling. 




3 


Gateway sends ARQ to its Gatekeeper. 




4 


Gatekeeper A issues LRQ (uni/multicast) to Gatekeeper B. * 




5 


Gatekeeper B returns LOF. * 




6 


Gatekeeper A returns AGF. 




7 


Gateway sends SETUP to its Gatekeeper (including fast connect options). 




8 


Gatekeeper A forwards SETUP to Gatekeeper B. * 




9 


Gatekeeper B forwards SETUP to Terminal. 




10 


Terminal performs ARQ/ACF sequence. 




11 


Terminal sends ALERT message back. 




12 


The Telephone should be informed that the Terminal is alerted and the user should hear "" 
appropriate tones. 




13 


After the User of the Terminal has answered the call, a CONNECT message should be forwarded 
to the Telephone and Media should be present immediately. 




14 


Media is exchanged and quality is evaluated. 




15 


The Telephone should release the call. 




16 


The Gateway should send a RELEASE_COMPLETE to its Gatekeeper and 
proceed to de-establish the call on the SCN side. 




17 


The Gatekeeper(s) forward(s) the RELEASE_COMPLETE to the Terminal. 




18 


The User is informed that the call was terminated by the remote peer and 
the Terminal should send a DRQ to its Gatekeeper. 




19 


The Gateways should send the DRQ to its Gatekeeper, after all resources associated with this call 
were released. 





* only present if this test is run with two Gatekeepers 

If there are three Gatekeepers involved, the procedure should be extended accordingly. 

9.2.3 Unsuccessful Call from a Terminal to an "unknown SCN Number" 

This test verifies the TIPHON Scenario- 1 service where the Originating Terminal and the Terminating Gateway are 
registered with the same Gatekeeper or where the two Gatekeepers have a trusted relationship, but the connection fails 
as the Number can not be terminated in the SCN. 



No. 


Action 


succeeded 


1 


Terminal A1 shall register with its respective Gatekeeper. 




2 


Terminal A1 initiates a call using a E.I 64 address. 




3 


Terminal A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A issues LRQ (uni/multicast) to Gatekeeper B. * 




5 


Gatekeeper B returns LRJ, indicating an unknown number. * 




6 


Gatekeeper A returns ARJ. 




7 


The user should be informed that the call failed indicating the cause. 





* only present if this test is run with two Gatekeepers 

If there are three Gatekeepers involved, the procedure should be extended accordingly. 
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9.2.4 Unsuccessful call with voice after DISCONNECT 

This test verifies the abihty to transfer data in after a DISCONNECT message was received (on the SCN side) using 
TIPHON Scenario- 1 service where the Originating Terminal and the Terminating Gateway are registered with the same 
Gatekeeper or the Gatekeepers have a trusted relationship. 

NOTE: The in-band information generated by the announcement machine is sent during the release of the call. 



No. 


Action 


succeeded 


1 


Both Terminal A1 and the Gateway B1 shall register with their respective Gatekeeper(s). 




2 


Terminal A1 initiates a call using a E.I 64 address. 




3 


Terminal A1 sends ARC to Gatekeeper A. 




4 


Gatekeeper A issues LRQ (uni/multicast) to Gatekeeper B. * 




5 


Gatekeeper B returns LOF. * 




6 


Gatekeeper A returns AGF. 




7 


Terminal A1 sends SETUP to its Gatekeeper (including fast connect options). 




8 


Gatekeeper A forwards SETUP to Gatekeeper B. * 




9 


Gatekeeper B forwards SETUP to Gateway B. 




10 


Terminating Gateway B performs ARQ/ACF sequence. 




11 


Gateway B initiates call establishment to SON. 




12 


The SON answers using a DISCONNECT IVIessage, indicating that there is a voice message 
present in the media channel. 




13 


Gateway B sends a PROGRESS Message to its Gatekeeper (including fast connect option). 




14 


The PROGRESS Message is forwarded to the Terminal and Media is switched on. 




15 


The Message should be presented to the User. 




16 


Terminal A1 terminates the call and 

sends a RELEASE_COMPLETE and a DRQ to its Gatekeeper. 




17 


The Gatekeeper(s) forward(s) the RELEASE_COMPLETE to the Gateway. 




18 


The Gateway initiates a call de-establishment to the SCN. 




19 


The Gateway should send the DRQ to its Gatekeeper, after all resources associated with this call 
were released.. 





only present if this test is run with two Gatekeepers 

If there are three Gatekeepers involved, the procedure should be extended accordingly. 

The only difference between "0 Unsuccessful call with voice after disconnect"and "0 Unsuccessful call with voice 
before connect" is the behaviour of the SCN, sending a PROGRESS or a DISCONNECT Message. 
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9.2.5 Unsuccessful call with voice before connect 

This test verifies the abihty to transfer data before CONNECT message was received using TIPHON Scenario- 1 service 
where the Originating Terminal and the Terminating Gateway are registered the same Gatekeepers or the Gatekeepers 
have a trusted relationship. 

NOTE: The in-band information generated by the announcement machine is sent before the active phase of the 
call i.e. SCN will never generate a CONNECT message. 



No. 


Action 


succeeded 


1 


Both Terminal A1 and the Gateway B1 shall register with their respective Gatekeeper(s). 




2 


Terminal A1 initiates a call using a E.I 64 address. 




3 


Terminal A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A issues LRQ (uni/multicast) to Gatekeeper B. * 




5 


Gatekeeper B returns LGF. * 




6 


Gatekeeper A returns AGF. 




7 


Terminal A1 sends SETUP to its Gatekeeper (including fast connect options). 




8 


Gatekeeper A forwards SETUP to Gatekeeper B. * 




9 


Gatekeeper B forwards SETUP to Gateway B. 




10 


Terminating Gateway B performs ARQ/ACF sequence. 




11 


Gateway B initiates call establishment to SON. 




12 


The SON answers using a PROGRESS IVIessage, indicating that there is a voice message present 
in the media channel. 




13 


Gateway B forwards PROGRESS IVIessage to its Gatekeeper (including fast connect option). 




14 


The PROGRESS Message is forwarded to the Terminal and IVIedia is switched on. 




15 


The Message should be presented to the User. 




16 


Terminal A1 terminates the call and sends a RELEASE_GOMPLETE and a DRQ to its Gatekeeper. 




17 


The Gatekeeper(s) forward(s) the RELEASE_GOMPLETE to the Gateway. 




18 


The Gateway initiates a call de-establishment to the SON. 




19 


The Gateway should send the DRQ to its Gatekeeper, after all resources associated with this call 
were released. 





-* only present if this test is run with two Gatekeepers 

If there are three Gatekeepers involved, the procedure should be extended accordingly. 

The only difference between "0 Unsuccessful call with voice after disconnect"and "0 Unsuccessful call with voice 
before connect" is the behaviour of the SCN, sending a PROGRESS or a DISCONNECT Message. 

9.2.6 Unsuccessful Call from a Telephone to an "unknown IP Number" 

This test verifies the TIPHON Scenario-2 service where the Originating Gateway and the Terminating Terminal should 
be registered with the same Gatekeeper or where the two Gatekeepers have a trusted relationship, but the connection 
fails as the Terminating Terminal is not registered. 



No. 


Action 


succeeded 


1 


Gateway B1 shall register with its respective Gatekeeper. 




2 


Telephone should dial a number to reach Terminal A1 
this can be done using one or two stage dialling. 




3 


Gateway B1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper B issues LRQ (uni/multicast) to Gatekeeper A. * 




5 


Gatekeeper A returns LRJ, indicating an unknown number. * 




6 


Gatekeeper B returns ARJ. 




7 


The user should be informed that this number is not available, by playing a busy tone or an 
announcement. 





* only present if this test is run with two Gatekeepers 

If there are three Gatekeepers involved, the procedure should be extended accordingly. 

9.2.7 Authorization and Call Routing via Settlement Server 

This test verifies that a gatekeeper is able to successfully communicate with a settlement server to receive authorization 
and call routing information in an interoperable manner. 
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The reference configuration of the figure 3 shows the general interaction between the gatekeeper and the settlement 
server. The steps in the figure are: 

1) Source Endpoint sends H.323 Setup to Gatekeeper A. 

NOTE: This assumes Gatekeeper Routed Calls with pre-granted ARQs. 

2) Gatekeeper A sends <AuthorizationRequest> to OSP Server. 

3) OSP Server replies with <AuthorizationResponse>. 

4) Gatekeeper A continues call setup with H.323 Setup to Gatekeeper B. 

5) Gatekeeper B continues call setup with H.323 Setup to Destination Endpoint. 

6) Destination Endpoint accepts call. 

Note that this test scenario is strictly concerned with the interaction between Gatekeeper A and the OSP Server (steps 2 
and 3). 



H.323 Terminal 



Telephone 




Setup / 
Setup Ack 



<AuthReq> 



OSP 
Server 



Figure 3 : Authorization and Call Routing from Gatekeeper to Settlement Server 
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No. 


Action 


succeeded 


1 


Both Terminal A1 and the Gateway B1 shall register with their respective Gatekeeper(s). 
(all should use pre granted ARQ) 




2 


Terminal A1 initiates a call using a E.I 64 address. 




3 


Terminal A1 sends SETUP to its Gatekeeper (including fast connect options). 




4 


Gatekeeper A establishes a SSL Connection to the OSP Server. 




5 


Gatekeeper A sends AuthReq to the OSP Server. 




6 


OSP Server replies with AuthRsp including the call signalling address of Gatekeeper B. 




8 


Gatekeeper A forwards SETUP to Gatekeeper B. 




9 


Gatekeeper B forwards SETUP to Gateway B. 




11 


Gateway B initiates call establishment to SON. 




12 


After the ALERT IVIessage was received on the SCN side, it should be forwarded to the Terminal. 




13 


The User at the Terminal should be informed that the Telephone is ringing. 




14 


After the Telephone was picked up, the CONNECT message should be forwarded from the 
Gateway to the Terminal and Media should be present immediately. 




15 


Media is exchanged and quality is evaluated. 




16 


Terminal A1 terminates the call 

and sends a RELEASE_COMPLETE and a DRO to its Gatekeeper. 




17 


The Gatekeeper(s) forward(s) the RELEASE_COMPLETE to the Gateway. 




18 


The Gateway initiates a call de-establishment to the SCN. 




19 


The User at the Telephone should hear appropriate tones. 





9.2.8 Usage Report to Settlement Server 

This test verifies that gatekeepers are able to successfully communicate with a settlement server to provide usage 
information in an interoperable manner. 

The reference configuration of the figure 4 shows the general interaction between the gatekeepers and the settlement 
server. The steps in the figure are: 

7) Gatekeepers release call 

8) Gatekeeper A sends <UsageIndication> to OSP Server. 

9) OSP Server replies with <UsageConfirmation>. 

10) Gatekeeper B sends <UsageIndication> to OSP Server. 

1 l)OSP Server replies with <UsageConfirmation>. 

Note that this test scenario is strictly concerned with the interaction between the Gatekeepers and the OSP Server (steps 
8 to 11). 
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H.323 Terminal 




Telephone 




IP Network 
H.323 Gatekeeper A V / 





"J^k H.323 Gateway 

<UsageCnf> 



OSP Server 



Figure 4 : Usage Reporting to Settlement Server 



No. 


Action 


succeeded 


1 


Both Terminal A1 and the Gateway B1 shall register with their respective Gatekeeper(s). 
(all should use pre granted ARQ) 




2 


Terminal A1 initiates a call using a E.I 64 address. 




3 


Terminal A1 sends SETUP to its Gatekeeper (including fast connect options). 




4 


Gatekeeper A establishes a SSL Connection to the OSP Server. 




5 


Gatekeeper A sends AuthReq to the OSP Server. 




6 


OSP Server replies with AuthRsp including the call signalling address of Gatekeeper B. 




8 


Gatekeeper A forwards SETUP to Gatekeeper B. 




9 


Gatekeeper B forwards SETUP to Gateway B. 




11 


Gateway B initiates call establishment to SON. 




12 


After the ALERT IVlessage was received on the SCN side, it should be forwarded to the Terminal. 




13 


The User at the Terminal should be informed that the Telephone is ringing. 




14 


After the Telephone was picked up, the connect message should be forwarded from the Gateway 
to the Terminal and Media should be present immediately. 




15 


IVIedia is exchanged and quality is evaluated. 




16 


Terminal A1 terminates the call 

and sends a RELEASE_COMPLETE and a DRO to its Gatekeeper. 




17 


The Gatekeeper(s) forward(s) the RELEASE_GOI\/IPLETE to the Gateway. 




18 


The Gateway initiates a call de-establishment to the SCN. 




19 


The User at the Telephone should hear appropriate tones. 





9.2.9 Fast Connect Fallback to H.245 tunneling 

This test verifies the support of fallback for the Fast Connect Procedure. 

The calling party shall include the fastConnect parameter in the setup message and set the h245Tunneling to TRUE. The 
called party shall not include the fastStart IE in any message but set the h245Tunneling to TRUE. As a result, the call 
has to be established using a H. 225.0 tunnel for the H.245 connection. 

The high level call flow is described in 9.2. 1 or 9.2.2. 

9.2.1 H.245 Tunneling Fallback to plain H.245 

This test verifies the support of fallback for the H.245 tunneling Procedure as described in 8.2.1 of H.323 [8]. 
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The calling party shall not include the fastConnect parameters in the setup message, but set the h245Tunneling 
parameter to TRUE. The called party shall set the h245Tunneling element to FALSE. As a result the call has to be 
established using a separate H.245 connection. 

The high level call flow is described in 9.2.1 or 9.2.2. 

9.2. 11 The use of Alternate Gatekeeper structure during registration 

This test verifies the proper exchange of alternate Gatekeeper information and the handover during registration, if the 
primary Gatekeeper rejects the Gatekeeper discovery. 



No. 


Action 


succeeded 


1 


The Endpoint (Gateway of Terminal) performs a GRQ to a preconfigured Gatekeeper. 




2 


The Gatekeeper send back a GRJ with the reason set to "resourceUnavailable" and a list of 
Alternate Gatekeepers = {Gatekeeper B, prioritv=1l: 




3 


The Endpoint sends a GRQ to Gatekeeper B. 




4 


Gatekeeper B answers with GRC. 




5 


The Endpoint registers with Gatekeeper B by sending a RRQ. 




6 


Gatekeeper B accepts registration by sending RCF back to the Endpoint. 





9.2. 1 2 Automatical fallback to alternate Gatekeeper after registration 

This test verifies the proper exchange of alternate Gatekeeper information and the handover after registration, if the 
primary Gatekeeper no longer responds to keep Alive messages. 



No. 


Action 


succeeded 


1 


The Endpoint (Gateway of Terminal) performs a GRQ to a preconfigured Gatekeeper. 




2 


The Gatekeeper accepts the discovery and sends back a GGF. 




3 


The Endpoint registers with Gatekeeper A. 




4 


Gatekeeper A accepts registration by sending RCF back to the Endpoint, including a list of 
Alternate Gatekeepers = (Gatekeeper B, prioritv=1|; 




5 


Gatekeeper A is disconnected (network disconnection preventing any RAS communication) 




6 


The Endpoint send RRQ including the keep Alive bit set, but does not receive any answer. 




7 


Upon timeout, the Endpoint shall send GRQ to Gatekeeper B 




8 


Gatekeeper B shall accept the discovery and answers sending a GGF. 




9 


The Endpoint registers with Gatekeeper B by sendiung a RRQ. 




10 


Gatekeeper B accepts registration by sending RCF back to the Endpoint. 





9.3 Telephone to Telephone using IP Network 



j j™ -SCN— ►I 



IP 

(RTP/RTCP) 



Telephone 



Gateway A1 



S 



GatevJay B1 



ffi 



Telephone 



lar 



Gatekeeper B 



Gatekeeper A 
NQTE: Gatekeeper B is only present in specific test cases. 

Figure 5: Telephone to Telephone using IP Network 

All tests can be executed with one or more Gatekeepers. The Number of Gatekeepers is just another parameter for these 

tests. 
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Direction 


Description 


Test Flow 


Extra feature 


Comment 


Tel A -> Tel B 


Successful call 





Fast connect 


TIPHON Scenario 3 


Tel B -> Tel A 


Successful call 


9.3.1 


Fast connect 


TIPHON Scenario 3 


Tel A -> Tel B 


Successful call 


9.3.5 


Fast connect fallback 


TIPHON Scenario 3 


Tel B -> Tel A 


Successful call 


9.3.5 


Fast connect fallback 


TIPHON Scenario 3 


Tel A -> Tel B 


Successful call 


9.3.6 


H.245 tunnelling 


TIPHON Scenario 3 


Tel B -> Tel A 


Successful call 


9.3.6 


H.245 tunnelling 


TIPHON Scenario 3 


Tel A -> Tel B 


Successful call 


9.3.4 


H.245 tunnelling fallback 


TIPHON Scenario 3 


Tel B -> Tel A 


Successful call 


9.3.4 


H.245 tunnelling fallback 


TIPHON Scenario 3 


Tel A -> Tel. B 


Successful call 


t.b.d 


Overlapped sending 


TIPHON Scenario 3 


Tel B -> Tel. B 


Successful call 


t.b.d 


Overlapped sending 


TIPHON Scenario 3 


Tel A <-> Tel. B 


Successful call 


t.b.d 


DTIVIF transmission 


TIPHON Scenario 3 


Tel A -> Tel B 


Basic unsuccessful 
call 


9.3.2 




TIPHON Scenario 3 


Tel B -> Tel A 


Basic unsuccessful 
call 


9.3.2 




TIPHON Scenario 3 


Tel A -> Tel B 


Authorization and 
Call Routing via 
Settlement Server 


9.3.3 


OSP 


TIPHON Scenario 3 


Tel A -> Tel B 


Authorization and 
Call Routing via 
Settlement Server 


9.3.3 


OSP 


TIPHON Scenario 3 


Tel A -> Tel B 


Usage Reporting to 
Settlement Server 


9.3.4 


OSP 


TIPHON Scenario 3 


Tel A -> Tel B 


Usage Reporting to 
Settlement Server 


9.3.4 


OSP 


TIPHON Scenario 3 



9.3.1 Successful call from a Telephone to a Telephone using IP Network 

This test verifies the TIPHON Scenario-3 service where the Originating Gateway and the Terminating Gateway are 
registered with the same Gatekeeper or where the two Gatekeepers have a trusted relationship. 



No. 


Action 


succeeded 


1 


Both Gateways A1 and B1 shall register with their respective Gatekeeper(s). 




2 


The Telephone calls Gateway A1 and initiates a call to Telephone B. 




3 


Gateway A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A issues LRO (uni/multicast) to Gatekeeper B. * 




5 


Gatekeeper B returns LCF. * 




6 


Gatekeeper A returns ACF. 




7 


Gateway A1 sends SETUP to its Gatekeeper (including fast connect options). 




8 


Gatekeeper A forwards SETUP to Gatekeeper B. * 




9 


Gatekeeper B forwards SETUP to Gateway B. 




10 


Terminating Gateway B performs ARO/ACF sequence. 




11 


Gateway B initiates call establishment to SCN. 




12 


After the ALERT IVIessage was received on the B SCN, it should be forwarded to the Gateway A1 . 




13 


The User at the Telephone A should be informed that Telephone B is ringing. 




14 


After Telephone B was picked up, the CONNECT message should be forwarded from the Gateway 
to the Gateway and Media should be present immediately. 




15 


IVIedia is exchanged and quality is evaluated. 




16 


Telephone A terminates the call. 




17 


Gateway A1 send a RELEASE_COMPLETE and to its Gatekeeper. 




18 


The Gatekeeper(s) forward{s) the RELEASE_COI\/IPLETE to Gateway. B 




19 


The Gateway B initiates a call de-establishment to the SCN B. 




20 


The User at the Telephone B should hear appropriate tones. 




21 


The Gateways should send the DRO to its Gatekeeper, after all resources associated with this call 
were released. 





* only present if this test is run with two Gatekeepers 

If there are three Gatekeepers involved, the procedure should be extended accordingly. 
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9.3.2 Unsuccessful call from a Telephone to a Telephone using IP 
Network 

This test verifies the TIPHON Scenario-3 service where the Originating Gateway and the Terminating Gateway are 
registered with the same Gatekeeper or where the two Gatekeepers have a trusted relationship, but the connection fails 
as the Number can not be terminated in the SCN. 



No. 


Action 


succeeded 


1 


Both Gateways A1 and B1 shall register with their respective Gatekeeper(s). 




2 


The Telephone calls Gateway A1 and initiates a call to a Telephone. 




3 


Gateway A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A issues LRQ (uni/multicast) to Gatekeeper B. * 




5 


Gatekeeper B returns LOF. * 




6 


Gatekeeper A returns AGF. 




7 


Gateway A1 sends SETUP to its Gatekeeper (including fast connect options). 




8 


Gatekeeper A forwards SETUP to Gatekeeper B. * 




9 


Gatekeeper B forwards SETUP to Gateway B. 




10 


Terminating Gateway B performs ARQ/ACF sequence. 




11 


Gateway B initiates call establishment to SON. 




12 


The call could not be terminated in the SON. 




13 


The User at the Telephone A should be informed that the call could not be completed. 




14 


After the Telephone A terminates the call, a RELESASE_GOMPLETE should be sent to 
Gatekeeper A. 




15 


The Gatekeeper(s) forward{s) the RELEASE_GOMPLETE to Gateway B. 




16 


The Gateway B initiates a call de-establishment to the SON B. 




17 


The Gateways should send the DRQ to its Gatekeeper, after all resources associated with this call 
were released. 





-* only present if this test is run with two Gatekeepers 

If there are three Gatekeepers involved, the procedure should be extended accordingly. 

9.3.3 Authorization and Call Routing via Settlement Server 

This test verifies that a gateway (acting without a gatekeeper present) is able to successfully communicate with a 
settlement server to receive authorization and call routing information in an interoperable manner. 

The reference configuration of the figure 6 shows the general interaction between the gateway and the settlement server. 
The steps in the figure are: 

1) Gateway A requires settlement services for a call. 

2) Gateway A sends <AuthorizationRequest> to OSP Server. 

3) OSP Server replies with <AuthorizationResponse>. 

4) Gateway A sends H.323 Setup to Gateway B. 

5) Destination Endpoint accepts call. 

Note that this test scenario is strictly concerned with the interaction between Gateway A and the OSP Server (steps 2 
and 3). 
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Telephone 



©ring A 
phone %j^ 



Setup / 
Setup Ack 



e 

<AuthReq> 



H.323 Gatew ay B 




Figure 6 : Authorization and Call Routing from Gatekeeper to Settlement Server 



No. 


Action 


succeeded 


1 


The Telephone calls Gateway A1 and initiates a call to Telephone B. 




2 


Gateway A establishes a SSL connection to OSP Server 




3 


Gateway A sends AuthReq to the OSP Server. 




4 


OSP Server accepts Authorization and replies with AuthRsp. 




5 


Gateway A sends SETUP to Gateway B (including fast connect options). 




6 


Gateway B initiates call establishment to SCN. 




7 


After the ALERT IVIessage was received on the B SCN, it should be forwarded to the Gateway A. 




8 


The User at the Telephone A should be informed that Telephone B is ringing. 




9 


After Telephone B was picked up, the CONNECT message should be forwarded to the Gateway 
and Media should be present immediately. 




10 


Media is exchanged and quality is evaluated. 




11 


Telephone A terminates the call. 




12 


Gateway A send a RELEASE_COMPLETE and to Gateway B. 




13 


The Gateway B initiates a call de-establishment to the SCN B. 




14 


The User at Telephone B should hear appropriate tones. 





9.3.4 Usage Reporting to Settlement Server 

This test verifies that gateways are able to successfully communicate with a settlement server to provide usage 
information in an interoperable manner. 

The reference configuration of the figure 7 shows the general interaction between the gateways and the settlement 
server. The steps in the figure are: 

6) Gateways release call 

7) Gateway A sends <UsageIndication> to OSP Server. 

8) OSP Server replies with <UsageConfirmation>. 

9) Gateway B sends <UsageIndication> to OSP Server. 

10) OSP Server replies with <UsageConfirmation>. 

Note that this test scenario is strictly concerned with the interaction between the Gateways and the OSP Server (steps 7 
to 10). 
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Telephone 




H.323 Gatew ^ B 

e 

<Usagelnd> 



Figure 7 : Usage Reporting to Settlement Server 



No. 


Action 


succeeded 


1 


The Telephone calls Gateway A and initiates a call to Telephone B. 




2 


Gateway A establishes a SSL connection to OSP Server 




3 


Gateway A sends AuthReq to the OSP Server. 




4 


OSP Server accepts Authentication and replies with AuthRsp. 




5 


Gateway A sends SETUP to Gateway B (including fast connect options). 




6 


Gateway B initiates call establishment to SCN. 




7 


After the ALERT IVIessage was received on the B SCN, it should be forwarded to the Gateway A. 




8 


The User at the Telephone A should be informed that Telephone B is ringing. 




9 


After Telephone B was picked up, the CONNECT message should be forwarded to the Gateway 
and Media should be present immediately. 




10 


IVIedia is exchanged and quality is evaluated. 




11 


Telephone A terminates the call. 




12 


Gateway A1 send a RELEASE_COMPLETE and to Gateway B. 




13 


The Gateway B initiates a call de-establishment to the SCN B. 




14 


The User at the Telephone B should hear appropriate tones. 




15 


Gateway A sends Usagelndication to the OSP Server. 




16 


OSP Server sends UsageConfirm to Gateway A. 




17 


Gateway B sends Usagelndication to the OSP Server. 




18 


OSP Server sends UsageConfirm to Gateway B. 




19 


Gatekeeper A sends Usagelndication to the OSP Server. 




20 


OSP Server sends UsageConfirm to Gatekeeper A. 




21 


Gatekeeper B sends Usagelndication to the OSP Server. 




22 


OSP Server sends UsageConfirm to Gatekeeper B. 





9.3.5 Fast Connect Fallback to H.245 tunneling 

This test verifies the support of fallback for the Fast Connect Procedure. 

The calling party shall include the fastConnect parameter in the setup message and set the h245Tunneling to TRUE. The 
called party shall not include the fastStart IE in any message but set the h245Tunneling to TRUE. As a result, the call 
has to be established using a H. 225.0 tunnel for the H.245 connection. 

The high level call flow is described in 9.3.1. 
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9.3.6 H.245 Tunneling Fallback to plain H.245 

This test verifies the support of fallback for the H.245 tunneling Procedure as described in 8.2.1 of H. 323 [8]. 

The calling party shall not include the fastConnect parameters in the setup message, but set the h245Tunneling 
parameter to TRUE. The called paity shall set the h245Tunneling element to FALSE. As a result the call has to be 
established using a separate H.245 connection. 

The high level call flow is described in 9.3.1 . 

9.4 Terminal to Terminal using SCN Network 



IP 

(RTP/RTCP) Gateway A2 

■4 ->|| E===J k- 




Gatekeeper A 




IP 
Ga teway B2 (rtp/rtcp) 
C U ►||! :::::::::::.^:; ||^ 

N I SCN 



□ 




Gatekeeper B 



Possible Tests: 



Direction 


Description 


Test Flow 


Extra feature 


Comment 


A1 -> B1 


Successful call 


9.4.1 


Fast connect 


TIPHON Scenario 4 


B1->A1 


Successful call 


9.4.1 


Fast connect 


TIPHON Scenario 4 


A1 -> B1 


Successful call 


9.4.1 


H.245 tunnelling 


TIPHON Scenario 4 


B1->A1 


Successful call 


9.4.1 


H.245 tunnelling 


TIPHON Scenario 4 


A1 ->D 


Basic unsuccessful 
call 


9.4.2 




TIPHON Scenario 4 


B1 ->D 


Basic unsuccessful 
call 


9.4.2 




TIPHON Scenario 4 
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9.4.1 Successful call from a H.323 Terminal to a H.323 Terminal using 
SCN Network 

This test verifies the TIPHON Scenario-4 service where the Originating Terminal and Gateway are registered to one 
Gatekeeper and the Terminating Gateway and Terminal are registered to another Gatekeeper. 



No. 


Action 


succeeded 


1 


All Terminals and Gateways should register with their respective Gatekeepers. 




2 


Terminal A1 initiates a call using a E.I 64 address. 




3 


Terminal A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A returns AGF. 




5 


Terminal sends setup to Gatekeeper A 




6 


Gatekeeper A forwards SETUP to Gateway A2. 




7 


Gateway A2 performs ARQ/AGF sequence. 




8 


Gateway A2 initiates an outgoing call to Gateway B1 . 




9 


Gateway B2 detects an incoming call and send an ARQ to Gatekeeper B. 




10 


Gatekeeper B responds with an AGF. 




11 


Gateway B2 sends SETUP to Gatekeeper B. 




12 


Gatekeeper(s) forward(s) SETUP to Terminal B1 . 




13 


Terminal B1 send ARQ to Gatekeeper B. 




14 


Gatekeeper B answers with AGF. 




15 


Terminal B1 accepts the call and sends an ALERT Message. 




16 


Terminal send ALERT message back. 




17 


The originating Terminal should be informed that the other side is alerted. 




18 


After the User of the Terminal has answered the call, a GQNNEGT message should be forwarded 
to the originating side, and IVIedia should be present immediately. 




19 


IVIedia is exchanged and quality is evaluated. 




20 


Terminal B1 sends a RELEASE_COMPLETE and a DRQ to the Gatekeeper B. 




21 


The Gatekeeper B forwards this to the Gateway B2. 




22 


The Gateway B2 should terminate the SCN call to Gateway A1 . 




23 


Gateway A2 sends a RELEASE_CQMPLETE to the Gatekeeper A. 




24 


Gatekeeper A should inform the Terminal A1 that the call is released. 




25 


Terminal A1 should inform the user that the remote peer terminated the call and send a DRQ to the 
Gatekeeper. 




26 


The Gateway A2 and B2 should send a DRQ to their Gatekeepers, after all resources have been 
released. 





9.4.2 Unsuccessful call from a H.323 Terminal to a H.323 Terminal using 
SCN Network 

This test verifies the TIPHON Scenario-4 service where the Originating Terminal and Gateway are registered to one 
Gatekeeper and the Terminating Gateway and Terminal are registered to another Gatekeeper. The call can not be 
completed as the called Terminal is not registered with its Gatekeeper. 



No. 


Action 


succeeded 


1 


All Terminals and Gateways should register with their respective Gatekeepers. 




2 


Terminal A1 initiates a call using a E.164 address. 




3 


Terminal A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A returns LCF. 




5 


Terminal sends setup to Gatekeeper A 




6 


Gatekeeper A forwards SETUP to Gateway A2. 




7 


Gateway A2 performs ARQ/AGF sequence. 




8 


Gateway A2 initiates an outgoing call to Gateway B1 . 




9 


Gateway B2 detects an incoming call and send an ARQ to Gatekeeper B. 




10 


Gatekeeper B responds with an ARJ. 




11 


Gateway B2 disconnects SCN call providing the proper DISCONNECT CAUSE. 




12 


Gateway A2 sends RELEASE_COMPLETE to Gatekeeper A including the CAUSE. 




13 


Gateway A2 forwards RELEASE_COIVIPLETE to Terminal A1 including the CAUSE. 




14 


The User at Terminal 1 is informed that the called user is not reachable and the CAUSE is 
presented. 
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